<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>

<head>
<meta name="GENERATOR" content="TtH 3.67">
 <style type="text/css"> div.p { margin-top: 7pt;}</style>
 <style type="text/css"><!--
 td div.comp { margin-top: -0.6ex; margin-bottom: -1ex;}
 td div.comb { margin-top: -0.6ex; margin-bottom: -.6ex;}
 td div.hrcomp { line-height: 0.9; margin-top: -0.8ex; margin-bottom: -1ex;}
 td div.norm {line-height:normal;}
 span.roman {font-family: serif; font-style: normal; font-weight: normal;} 
 span.overacc2 {position: relative;  left: .8em; top: -1.2ex;}
 span.overacc1 {position: relative;  left: .6em; top: -1.2ex;} --></style>
 

      
<title> Visual Workflow Editor</title>
</head>

<body>


<h1><a name="tth_chAp2"></a>Methodology and Technology</h1>
<a name="ch:methodology"></a>

<h2><a name="tth_sEc1"></a>Methodology</h2>

<p>
One of the main objective of the project has been to generate the code
for the visual editor from a model describing the OGSA-DAI
workflow. Models are usually used to achieve a better understanding of
a problem and for documentation purpose. But, models can also be used
to generate automatically code. The idea behind this concept is build
the model at the begin of the development life cycle. This would
improve improving the code quality, because the automatic generation
of code prevents bugs. Another parameter that would be affected is the
productivity: a single model can be used to describe the problem
domain, generate the code, and to document it.
</p>

<p>
The methodology used to achieve the goal, is called Model Driven
Development (MDD). The <a href="#sec:model">section</a>
introduces the concepts of <i>model and meta-model</i>, meanwhile this
<a href="#sec:mdd">section</a> gives a brief overview of MDD and the
key technologies related to it.
</p>

<h3><a name="tth_sEc1.1"></a>Model and meta-model</h3>
<a name="sec:model"></a>

<p>
A model is an abstract description of a problem that hides information
about some aspects of it. A valid definition of model is provided by:
</p>

<blockquote>
A model is a simplification of a system built with an intended goal in
mind. The model should be able to answer questions in the place of the
actual system.  
</blockquote>

<p>
The idea behind a model is that it should be easier to use than the
original system in such a way that many details from the source system
are abstracted out, and only a few are implemented in the target
model. A model allows the domain problem to be described by using
terms that are familiar to the domain expert rather than terms that
are familiar only to IT experts.
</p>

<p>
A specific model can be identified from the problem domain using a
specific meta-model. Different models of the same system can be
observed and manipulated, and each model can be represented by a
different meta-model. A meta-model can be defined as:
</p>

<blockquote>
A meta-model is the explicit specification of an abstraction. In order
to define the abstraction, the meta-model identifies a list of
relevant concepts and a list of relevant relationships between these
concepts.  
</blockquote>

<p>
A metamodel specifies the set of elements that should be considered
while creating a model, and the scope of what may be defined in a
model, what elements may be contained in the model and how these
elements relate to each other. Metamodel abstracts from specific
implementation technologies and it focuses only on defining domain
concepts.  
</p>

<h3><a name="tth_sEc1.2"></a>Model driven development</h3><a name="sec:mdd">
</a>

<p>
The MDA has been defined in 2001 by the OMG, to provide a new paradigm
of software development. MDA is based on other OMG's technologies:
UML, the Meta Object Facility (MOF) and XML Metadata Interchange
(XMI).  The MDA specification covers the complete life cycle of a
product from the design to deployment, integration, and
management. The specification was designed taking into consideration
several objectives: portability and reusability, cross-platform
inter-operability, platform independence, domain specificity,
productivity.
</p>

<p>
The <i>MDD</i>, an OMG trademark, is the specific application of MDA
methodology, and it focuses on model visualisation and model
transformations. The aim of the MDD is to raise the level of
abstraction in development approach providing a set of tools to
automate the software life cycle.
</p>


<a name="tth_fIg1"></a> 	
<center>
<img src="gfx/model_driven_architecture.png" alt="gfx/model_driven_architecture.png" />
<br/>    	
Figure 1: Model Driven Architecture
<a name="fig:model_driven_architecture"></a>
</center>


<p>
The <a href="#fig:model_driven_architecture">Figure&nbsp;1</a> shows
that MDA defines a clear distinction between Platform Independent
Models (PIM) and Platform Specific Models (PSM). The software
development process can be divided in three steps:
</p>

<ol type="1">
<li> 
The Platform Independent Model is designed, using modelling concepts
which are not platform specific. The PIM is a pure UML model, with
constraints specified in the Object Constraint Language (OCL).
</li>

<li> 
The Platform Specific Model, containing additional UML models, is
generated. The PSM represents an implementation of the system under
design which can run on the target platform. The transition between
PIM and PSM should typically be facilitated using automated model
transformation technology.
</li>

<li>
The application code is generated from the Platform Specific Model. In
order to minimise the manual coding, that is slow and error-prone, the
code generation should be as extensive as possible.
</li>
</ol>


<p>
The domain-specific language used by MDA to define modelling languages
is MOF: a MOF model is a definition of an MDA modelling language. MOF
defines also how an MDA modelling language can be serialised into an
XML document, and is primarily a technology for the storage of
conceptual models and interchanging them using another language called
XMI.
</p>

<p>
XML Metadata Interchange is a standard that connects MOF with XML, and
defines a simple way to specify model objects in XML documents. An XMI
document's structure closely matches with the corresponding MOF model,
with the same names and an element hierarchy that follows the model's
containment hierarchy. As a result, the relationship between a model
and its XMI serialisation is easy to understand.
</p>

<div class="p"><!----></div>
 <h2><a name="tth_sEc2"></a>Technology</h2>

<p>
The technologies used to follow the MDD methodology, belong to Eclipse
Modelling Projec and they are:
</p>

<ul>
<li> <i>EMF</i></li>

<li> <i>GMF</i></li>

</ul>

<h3><a name="tth_sEc2.1"></a>EMF</h3>

<p>
<i>EMF</i> is an Eclipse framework for modelling and code
generation. It was started as MOF implementation and represent and
enhancement of the MOF2.0 specification.  Models can be specified
using annotated Java, XML documents, XMI or ecore file and then they
can be imported into EMF. From a model specification EMF provides
tools and runtime support to produce a set of Java classes for the
model, a set of adapter classes that enable viewing and editing model
and a basic editor.  EMF includes its own metamodel called Ecore which
is used for describing models and runtime support for models. Ecore
metametamodel is shown in Figure&nbsp;<a
href="#fig:ecore_metamodel">2</a> and it is compliant with MOF. The
runtime support includes notification, persistence and XMI
serialisation.
</p>

<a name="tth_fIg2"></a> 	
<center>	
<img src="gfx/ecore_metamodel.png" alt="gfx/ecore_metamodel.png" />
<br/>    	
Figure 2: Ecore metamodel
<a name="fig:ecore_metamodel"></a>
</center>

<p>
From an EMF model, a set of Java classes for the model and a tree
based editor can be generated. The generated code provides a basic
support for managing model elements and serializing them.
</p>

<h3><a name="tth_sEc2.2"></a>GMF</h3>

<p>
The Eclipse Graphical Modelling Framework (GMF) was started as an
Eclipse Technology subproject with the objective to provide a
generative component and runtime infrastructure for developing
graphical editors in Eclipse. GMF introduced the notion of the
"mapping metamodel", specifying a generative bridge between
conceptually separated diagram (concrete syntax) and logical model
(abstract syntax) layers. It uses EMF and GEF in a generative manner
to create domain-specific editors.  Figure<a
href="#fig:gmf_overview">3</a> shows the main elements that are used
during GMF-based development
</p>

<a name="tth_fIg3"></a> 	
<center>	
<img src="gfx/gmf_overview.png" alt="gfx/gmf_overview.png" />
<br/>    	
Figure 3: GMF overview
<a name="fig:gmf_overview"></a>
</center>

<p>
The step to follow to create a visual diagram in GMF are:
</p>

<ol type="1">
<li> 
Domain model: using EMF it's necessary to define the abstract
syntax(metamodel) of the diagram. This metamodel should define the
language concepts and relationships.
</li>

<li> 
Graphical definition: is used to define the graphical elements that
will be displayed. The graphical element are not directly related with
the elements of the Domain model (for which they provide a visual
representation): the linking will take place in a different step,
using a mapping model
</li>

<li> 
Tooling definition: This is an optional component, and is used to
define control elements of the GUI like the palette, menus, toolbars,
etc.
</li>

<li> 
Mapping model: This is the central point in GMF development, and it is
used to link all together the previous models. Taking as input the
domain model, the tooling definitions and the graphical model it
produces as output the final model, called <i>generator model</i>.
</li>

<li> 
Generator model: this model is used to define the details about the
final diagram code, and gives the possibility to obtain as final
result an eclipse plugin or a standalone Rich Client Platform (RCP)
application
</li>

</ol>


<h3><a name="tth_sEc2.3"></a>Rich Client Platform</h3>

<p>
Thanks to the methodology adopted to develop the application, it has
been possible to focus mainly on the description and modelling of the
domain. The EMF and GMF frameworks are in charge of generating
automatically the code, including all the packages that are
implementing the UI. Potentially, the developer would never be
involved with issues about the framework used to build the graphical
user interface. Due to the specificity of the project, it has been
necessary to modify the generated code, and to add custom graphical
elements. For this reason it has been required to familiarise with the
<i>RCP</i> framework.
</p>


<p>
The RCP framework is built of top of the Standard Widget Toolkit
(SWT), and is the core component of the Eclipse Workbench. Being a
complete independent framework, it is possible to use it to embed the
same functionalities that are present in Eclipse in new, stand-alone
applications. The most important characteristic of this solution, is
the Plug-in functionality, in which a plug-in is considered as the
smallest unit that is possible to plug in the overall architecture. A
plug-in can be embedded in an existent product, using extension
points, and no change is needed in the original application.
</p>


Both EMF and GMF, use this architecture to generate code, thus in
order to add new functionalities to th code, is enough to create a new
plug-in, defining the extension point. A complete explanation of this
framework is beyond the scope of this thesis and can be found in.

</body>
</html>